Q: this seems like a refactor. How does this support translational? Also, why put proto methods that are implemented once on an interface instead of keeping as a utility and ifc lean?

@edaniels the main/only thing gating translational joint support prior to this PR, is that arm joint positions are passed in as a list of raw floats, which are currently assumed to be in degrees and are converted to radians. If something with a translational joint receives the joint positions proto message, it needs to know which of those raw floats should be converted from degrees to radians and which should not.

The ultimate source of truth for what sort of value something expects is the thing ultimately consuming it, which is what is implemented here. The actual frames that represent a rotational movement will call utils.DegToRad when provided the protobuf value, while the translational ones will not. This also leaves the door open for someone to pass in some other sort of value and write their own transformation.